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1  Scope 


1.1  Identification 

This  document  provides  a  description  of  the  activities  to  be  performed  by  the  U.S. 
Army  Construction  Engineering  Research  Laboratories  (USACERL)  during  the  design, 
development  and  testing  of  the  Computer  Software  Configuration  Item  (CSCI)  for  the 
Assessment  System  for  Aircraft  Noise  (ASAN)  Version  2.0.  This  Software  Develop¬ 
ment  Plan  (SDP)  is  identified  in  the  Statement  of  Work  (SOW)  as  CDRL  Exhibit  B, 
Sequence  10. 


1.2  System  Overview 

ASAN  is  a  computer  system  being  developed  to  model  the  effects  of  subsonic  and 
supersonic  aircraft  noise  from  Military  Training  Routes  (MTRs)  and  Military 
Operations  Areas  (MOAs).  The  piuT)ose  is  to  assist  U.S.  Air  Force  environmental  and 
route  planners  in  planning  minimal  impact  routes  and  in  producing  improved 
environmental  impact  analysis  documents. 

ASAN  is  sponsored  by  the  U.S.  Air  Force  Noise  and  Sonic  Boom  Impact  Technology 
Advanced  Development  Program  Office  (NSBIT),  which  sponsors  research  supporting 
the  preparation  of  scientifically  supportable  and  legally  defensible  environmental 
assessments  of  the  effects  of  aircraft  noise  on  humans,  animals,  and  structures.  ASAN 
Version  1.0  was  developed  by  Bolt  Beranek  and  Newman  Inc.,  Cambridge,  MA,  under 
Air  Force  Contracts  F33615-90-D-0653  and  F33615-86-C-0530.  ASAN  Version  2.0  will 
be  developed  by  USACERL,  Champaign,  IL,  under  MIPR  FQ76249500067. 


1.3  Document  Overview 

This  document  serves  two  purposes.  The  first  is  to  provide  the  information  necessary 
to  guide  project  management  of  the  ASAN  Version  2.0  software  development  effort. 
The  second  purpose  is  to  make  all  management  tasks  and  management  information 
visible  to  the  project  sponsor  and  other  interested  parties. 

All  software  for  the  ASAN  Version  2.0  project  will  be  developed  according  to  this 
formal  SDP.  This  plan  is  written  in  accordance  with  the  U.S.  Military  Standard  for 
Software  Development  and  Documentation  (MIL-STD-498)  and  the  subsidiary  Data 
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Item  Definition  (DID)  DI-IPSC-81427,  Software  Development  Plan.  This  SDP  contains 
the  sections  shown  in  Table  I  as  outlined  by  the  chosen  standard. 


Table  I  Structure  of  the  Software  Development  Plan 


1.  Scope 

2.  Referenced  Documents 

3.  Overview  of  Required  Work 

4.  Plans  for  Performing  General  Software  Development  Activities 

6.  Plans  for  Performing  Detailed  Software  Development  Activities 

6.  Schedules  and  Activity  Network 

7.  Project  Organization  and  Resources 

8.  Notes 


1.4  Relationship  to  Other  Plans 

The  ASAN  Version  2.0  project  is  organized  with  the  aid  of  two  managerial  documenta¬ 
tion  plans: 

1.  The  Software  Development  Plan  (SDP) — ^this  document 

2.  The  Software  Test  Plan  (STP). 

The  SDP  describes  the  approach  to  canying  out  all  software  development  activities, 
including  an  overview  of  the  plan  for  testing  the  software.  The  STP  expands  on  the 
testing  plan  defined  in  this  SDP  to  describe  the  detailed  approach  to  software 
qualification  testing,  including  a  description  of  the  software  test  environment  and 
identification  of  the  tests  to  be  performed. 
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2  Referenced  Documents 

2.1  Specifications 

SOW,  Assessment  System  for  Aircraft  Noise,  10  October  1995. 


2.2  Military  Standards 

MIL-STD-498,  Software  Development  and  Documentation,  5  December  1994. 


2.3  Other  Documents 

Reddingius,  Nicolaas  H.,  Software  Requirements  Specification  for  the  Beta  Version  of 
the  Assessment  System  for  Aircraft  Noise,  BBN  Report  No.  7653  (Bolt  Beranek  and 
Newman  Inc.,  14  January  1992). 

Reddingius,  Nicolaas  H.,  and  Shawntise  R.  Turner,  Software  User's  Manual  for  the 
Assessment  System  for  Aircraft  Noise,  BBN  Report  No.  7730  (Bolt  Beranek  and 
Newman  Inc.,  6  February  1995). 

Smyth,  John  S.,  Bruce  Papazian,  Nicolaas  H.  Reddingius,  and  Shawntise  R.  Turner, 
Software  Design  Document  for  the  Assessment  System  for  Aircraft  Noise,  BBN  Report 
No.  7654  (Bolt  Beranek  and  Newman  Inc.,  7  March  1995). 
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3  Overview  of  Required  Work 

3.1  Requirements  and  Constraints  on  the  Software  to  be  Developed 

Each  of  the  modifications  identified  in  sections  3.1.1  -  3.1.4  of  the  SOW  will  be 
incorporated  into  ASAN  Version  1.0  to  create  Version  2.0.  The  software  will  be 
developed  according  to  the  approach  defined  in  this  SDP. 


3.2  Requirements  and  Constraints  on  Project  Documentation 


The  documents  shown  in  Table  II  will  be  produced  to  record  the  ASAN  Version  2.0 
software  development  effort. 


Table  H  ASAN  Version  2.0  Documents 


DID 

Title 

DI-IPSC-81427/T 

Software  Development  Plan  (SDP)  -  this  document 

DMPSC-81438/T 

Software  Test  Plan  (STP) 

DI-IPSC-81433/T 

Software  Requirements  Specification  (SRS) 

DI-IPSC-81435/T 

Software  Design  Description  (SDD) 

DI-IPSC-81439 

Software  Test  Description  (STD) 

DI-IPSC-81441/T 

Software  Product  Specification  (SPS) 

DI-IPSC-81442/T 

Software  Version  Description  (SVD) 

DMPSC-81443/T 

Software  User  Manual  (SUM) 

The  existing  SRS,  SDD,  and  SUM  for  ASAN  Version  1.0  will  be  updated  to  define  the 
new  ASAN  Version  2.0  capabilities,  conforming  to  the  format  and  level  of  detail 
previously  established  in  the  documents.  The  SRS,  SDD,  and  SUM  will  not  be 
modified  for  any  unchanged  Version  1.0  capabilities.  The  remaining  documents  will 
be  written  by  USACERL  in  accordance  with  MIL-STD-498  and  the  subsidiary  DIDs. 


3.3  Position  op  the  Project  in  the  System  Life  Cycle 

ASAN  is  being  developed  using  an  evolutionary  life-cycle  model  where  the  software 
product  evolves  in  successively  larger  solutions.  ASAN  Version  1.0  is  a  functional 
software  program  currently  being  used  by  customers.  ASAN  Version  2.0  will  be 
developed  by  incorporating  modifications  and  enhancements  into  Version  1.0. 
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3.4  The  Selected  Program/Acquisition  Strategy 


This  paragraph  has  been  tailored  out. 


3.5  Requirements  AND  Constraints  ON  Project  Schedules  AND  Resources 

The  work  defined  in  the  SOW  will  be  completed  for  the  amount  of  funding  provided 
under  MIPR  FQ76249500067. 

All  deliverables  must  be  provided  to  NSBIT  no  later  than  12  months  from  the  date  of 
receipt  of  the  SOW. 

Each  document  will  be  provided  to  NSBIT  adhering  to  the  submission  requirements 
shown  in  Table  III. 


Table  III  Document  Submission  Requirements 


Document 

SDP 

SRS 

SDD,  architectural  design 
STP 

SDD,  detailed  design 

STD 

SUM 

SVD 

SDD,  as  tested 
SPS 


Submission  Requirement 
within  45  days  of  receipt  of  the  SOW 
30  days  prior  to  the  architectural  design  review 
15  days  prior  to  the  architectural  design  review 
15  days  prior  to  the  first  detailed  design  review 
15  days  prior  to  a  build’s  detailed  design  review 
30  days  prior  to  a  build's  qualification  test 
30  days  prior  to  a  build’s  qualification  test 
30  days  prior  to  a  build’s  qualification  test 
within  15  days  of  a  build’s  qualification  test 
within  30  days  of  the  final  qualification  test 


If  modifications  to  a  document  are  requested  by  NSBIT,  the  document  will  be 
resubmitted  to  NSBIT  for  approval  within  15  days  of  the  review  or  qualification  test. 
The  executable  software  and  a  final  copy  of  all  documents  will  be  delivered  to  NSBIT 
within  30  days  of  the  final  qualification  test. 


3.6  Other  Requirements  AND  Constraints 

The  ASAN  Version  2.0  software  will  be  developed  in  accordance  with  a  tailored  version 
of  the  MIL-STD-498  software  development  process  as  defined  in  this  SDP. 

The  software  shall  operate  under  SunOS  4.1.3,  Solaris  2.4,  and  IRIX  5.3  UNIX 
operating  systems. 
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4  Plans  for  Performing  General  Software  Develop¬ 

ment  Activities 

4.1  Software  Development  Process 

The  ASAN  Version  2.0  software  development  process  is  shown  in  Figure  1.  The 
documents  that  are  prepared  to  record  the  results  of  each  task  are  shown  below  each 
task  box.  The  process  consists  of  defining  the  software  requirements,  developing  an 
architectural  design,  developing  a  detailed  design,  implementing  and  testing  the 
software  capabilities  and  delivering  the  software  product. 

During  software  requirements  analysis,  the  software  capabilities  that  are  required  for 
acceptance  of  ASAN  Version  2.0  will  be  defined  and  recorded  in  the  SRS.  The 
architectural  design  will  be  documented  in  the  SDD,  which  will  include  Data  Flow  Dia¬ 
grams  illustrating  all  control  and  data  flow  activity,  interface  specifications,  and  func¬ 
tional  descriptions  of  the  software  components.  The  software  requirements  and  the 
architectural  design  will  be  reviewed  for  approval  at  a  Joint  Management/Technical 
Review. 

Following  acceptance  of  the  architectural  design,  the  ASAN  Version  2.0  modifications 
will  be  grouped  into  three  build  elements  as  shown  in  Table  IV.  The  detailed  design. 


Project,  Planning  and  Oversight 


SDP  STP 


SDD  STD,  SUM, 

SVD.SDD 


Figure  1  ASAN  Version  2.0  Software  Development  Process 
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implementation,  and  testing  of  each  build  element  will  be  scheduled  and  tracked 
separately.  This  approach  will  allow  development  to  progress  on  an  incremental  basis 
with  each  build  using  the  capabilities  that  were  implemented  and  tested  in  previous 
builds. 


Table  IV  Build  Elements 


Build 

Modification 

sow  Item 

1 

Select  Assessment  Area 

3.1.1.a:l 

1 

Printer  Control 

3.1.1.d 

1 

Toggle/Radio  Buttons 

3.1.1.g 

1 

MTR  Copy 

3.1.1.b 

1 

Version  1.0  Bug  Fixes 

3,1.4 

2 

Import/Export  Local  Data 

3.1.1.C 

2 

Auto  ROI 

3.1.1.f:l 

2 

Map  Save 

3.1.1.e 

2 

Version  1,0  Bug  Fixes 

3.1.4 

3 

PS.MAP  &  Postscript 

3.1.3.a 

3 

Highlight  Features  in  ROI 

3,l.l.f:2 

3 

Import  1.0  Assessment 

3.1.1.a:2 

3 

Version  1,0  Bug  Fixes 

3.1.4 

The  detailed  design  of  each  build  element  will  describe  how  the  design  will  be  imple¬ 
mented,  including  complete  descriptions  of  the  software  modules,  database  definitions, 
and  interface  details.  The  detailed  design  will  be  documented  in  the  SDD.  Each  build 
element  will  be  presented  at  detailed  design  level  at  a  Joint  Management/Technical 
Review.  The  approach  that  will  be  used  for  testing  the  software,  recorded  in  the  STP, 
will  be  reviewed  in  conjunction  with  the  detailed  design  of  Build  1. 

When  NSBIT  approves  a  build  element's  detailed  design,  the  build  element  will  be 
implemented  and  tested  by  USACERL.  The  SUM  will  be  updated  to  provide  a  guide 
for  operating  the  software.  A  description  of  the  test  cases  and  test  procedures  to  be 
used  for  the  build  element  will  be  recorded  in  the  STD.  The  SVD  will  identify  which 
capabilities  are  included  in  the  test  version  of  the  software. 

Each  build  element  will  have  a  separately  scheduled  qualification  test  where  the 
capabilities  will  be  tested  for  approval  by  a  NSBIT  representative.  Results  of  each 
qualification  test  will  be  recorded  in  the  STD.  The  SDD  will  be  updated  to  record  the 
final  design  of  the  build  element  as  it  was  tested  and  approved. 

After  the  final  build  element  has  been  tested  and  approved,  the  SPS  will  be  prepared. 
It  will  contain  or  reference  the  executable  software,  source  files,  and  software  support 
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information.  Delivery  of  the  software  will  be  accompanied  by  a  final  version  of  all 
documents. 

4.2  General  Plans  for  Software  Development 


4.2.1  Software  Development  Methods 

The  methodology  to  be  used  for  each  software  development  activity  is  described  in 
Section  5  of  this  SDP. 


4.2.2  Standards  for  Software  Products 

The  standards  to  be  followed  for  representing  requirements,  design,  code,  test  cases 
and  test  results  are  described  in  Sections  5.5  -  5.9  of  this  SDP. 

4.2.3  Reusable  Software  Products 

This  paragraph  has  been  tailored  out. 

4.2.4  Handling  of  Critical  Requirements 

This  paragraph  has  been  tailored  out. 


4.2.5  Computer  Hardware  Resource  Utilization 

ASAN  Version  2.0  will  be  designed  to  operate  under  the  minimum  hardware 
requirements  of  Version  1.0.  Design  decisions  that  would  increase  the  minimum 
requirements  will  be  subject  to  the  approval  of  NSBIT  in  a  Joint  Management/ 
Technical  Review. 


4.2.6  Recording  Rationale 

The  rationale  for  decisions  made  on  the  project  that  have  major  impact,  are 
controversial,  or  affect  a  large  portion  of  the  system  will  be  recorded  and  maintained 
in  the  software  development  files. 
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4.2.7  Access  for  Acquirer  Review 

Representatives  of  NSBIT  will  have  access  to  the  USACERL  software  engineering  and 
test  environments  for  review  of  software  products  and  activities  on  the  dates  of  the 
Joint  Management/Technical  Reviews  which  are  held  at  USACERL. 
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5  Plans  for  Performing  Detailed  Software  Development 
Activities 

5.1  Project  Planmnc  and  Oversight 

5.1.1  Software  Development  Planning 

The  results  of  software  development  planning  are  recorded  in  this  SDP.  If  necessary 
or  beneficial  changes  to  this  SDP  are  identified,  an  updated  SDP  will  be  submitted  to 
NSBIT  for  approval. 

5.1.2  CSCl  Test  Planning 

The  overall  approach  to  CSCI  test  planning  is  described  in  Section  5.9  of  this  SDP. 
The  detailed  plan  for  qualification  testing  will  be  defined  in  the  STP. 

5.1.3  System  Test  Planning 

This  paragraph  has  been  tailored  out. 

5.1.4  Software  Installation  Planning 

This  paragraph  has  been  tailored  out. 

5.1.5  Software  Transition  Planning 
This  paragraph  has  been  tailored  out. 

5.1.6  Following  and  Updating  Plans 


The  software  development  activities  for  this  project  will  be  conducted  in  accordance 
with  this  SDP.  The  status  of  all  activities  will  be  evaluated  in  the  Joint  Management/ 
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Technical  Reviews  to  assure  that  each  activity  is  being  performed  in  accordance  with 
the  plan.  Updates  to  this  SDP  will  be  subject  to  approval  from  NSBIT. 


5.2  Establishing  A  Software  Development  Environment 


5.2.1  Software  Engineering  Environment 

A  software  development  environment  will  be  established  in  the  Engineering  Processes 
Division  of  USACERL.  Since  ASAN  Version  2.0  will  be  developed  by  incorporating 
enhancements  into  existing  source  code  and  documentation,  it  will  be  most  time  and 
cost  efficient  to  update  the  products  with  the  tools  used  for  Version  1.0.  CASE  tools 
will  not  be  used.  The  environment  will  consist  of: 

•  4  Sun  workstations  running  SunOS  4.1.3 

•  1  Sun  workstation  running  Solaris  2.4 

•  1  SGI  workstation  nmning  IRIX  5.3 

•  X  Window  System 

•  Motif  Developer  Pack 

•  GRASS  4.1  source  code  and  executable  programs 

•  Oracle  7  developer  package  and  Pro*C  preprocessor 

•  ASAN  1.0  source  code  and  executable  programs 

•  sees  configuration  control  software 

•  Compilers  and  related  utilities:  gcc  (Sun),  cc  (SGI),  make,  Id,  ranlib,  awk,  sed, 
perl,  C  code  libraries  and  include  files 

•  Text  and  code  editors:  vi,  emacs,  vim 

•  Debuggers:  dbx,  ddd,  gdb 

•  3  DOS-based  computers 

•  WordPerfect  for  Windows  5.2 

•  PVeS  configuration  control  software. 

A  data  development  environment  will  be  established  in  the  Resource  Mitigation  and 
Protection  Division  of  USACERL  consisting  of: 

•  Sun  workstations 

•  DOS-based  computers 

•  Arc/Info  release  7.1  (TIN,COGO,GRID  extensions) 

•  Excel 

•  Oracle  release  7.1.x 

•  AreView 
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•  Pageview,  Ghostview 

•  AutoCad 

•  Wingz  spreadsheet 

•  GRASS  release  4.1 

•  Internet  tools  (Mosaic,  Ismx,  ftp) 

•  GRASS  contrib  libraries 

•  WordPerfect  5.1 

•  Proj  libraries. 

5.2.2  Software  Test  Environment 

The  software  test  environment  will  be  a  subset  of  the  software  development 
environment  described  in  Section  5.2.1  of  this  SDP.  It  consists  of: 

•  1  Sun  workstation  running  SimOS  4.1.3 

•  1  Sun  workstation  nmning  Solaris  2.4 

•  1  SGI  workstation  running  IRIX  5.3 

•  X  Window  System 

•  Motif  Window  Manager 

•  GRASS  4.1  executable  programs 

•  Oracle  7  executable  programs 

•  ASAN  executable  programs. 

5.2.3  Software  Development  Library 

The  software  that  is  produced  for  this  project  will  be  maintained  in  a  software 
development  library  under  the  SunOS  4.1.3  operating  system.  The  software  library 
will  be  controlled  using  SCCS  configuration  control  software.  The  project  documents 
will  be  maintained  in  a  documentation  library  on  a  DOS-based  server  using  PVCS 
Windows  configuration  control  software.  The  control  and  management  of  these 
libraries  is  described  in  Section  5.14  of  this  SDP. 


5.2.4  Software  Development  Files 

The  software  development  team  leader  will  maintain  software  development  files. 
These  files  will  contain  the  SOW,  ASAN  correspondence,  Joint  Management/Technical 
Review  notes  and  summary  reports,  status  reports,  problem/change  reports,  rationale 
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for  key  decisions,  test  cases  and  results,  and  a  copy  of  all  documents  prepared  for  this 
project. 


5.2.5  Non-Deliverable  Software 

Non-deliverable  software  will  be  developed  and  maintained  by  the  data  development 
team  for  specific  data  conversion  tasks. 


5.3  System  Requirements  Analysis 
This  paragraph  has  been  tailored  out. 


5.4  System  Design 

This  paragraph  has  been  tailored  out. 


6.5  Software  Requirements  Analysis 

The  SRS  will  be  created  by  modifying  the  Software  Requirements  Specification  for  the 
Beta  Version  of  the  Assessment  System  for  Aircraft  Noise  to  include  descriptions  of  the 
software  characteristics  that  are  required  for  acceptance  of  ASAN  Version  2.0. 
Changes  to  the  SRS  will  conform  to  the  format  and  level  of  detail  previously 
established  in  the  document.  The  SRS  will  be  reviewed  for  approval  by  NSBIT  at  a 
Joint  Management/Technical  Review. 


5.6  Software  Design 


5.6.1  CSCI-Wide  Design  Decisions 

Any  CSCI-wide  design  decisions  will  be  recorded  in  the  SDD  and  presented  for  review 
at  a  Joint  Management/Technical  Review. 
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5.6.2  CSCI  Architectural  Design 

The  architectural  design  will  he  performed  using  the  Ward/Mellor  design  methodology. 
The  existing  ASAN  SDD  will  be  modified  to  include  the  architectural  design  of  ASAN 
2.0  capabilities.  It  will  include  Data  Flow  Diagrams  illustrating  all  control  and  data 
flow  activity,  interface  specifications  and  functional  descriptions  of  the  software 
components.  Changes  to  the  SDD  will  conform  to  the  format  and  level  of  detail 
previously  established  in  the  document.  The  architectural  design  portion  of  the  SDD 
will  be  reviewed  for  approval  by  NSBIT  at  a  Joint  Management/Technical  Review. 


5.6.3  CSCI  Detailed  Design 

The  detailed  design  of  ASAN  2.0  capabilities  will  be  performed  using  the  Ward/Mellor 
design  methodology.  It  will  be  recorded  in  the  SDD,  including  complete  descriptions 
of  the  software  modules,  database  definitions,  and  interface  details.  Changes  to  the 
SDD  will  conform  to  the  format  and  level  of  detail  previously  established  in  the 
document.  The  detailed  design  portion  of  the  SDD  will  be  reviewed  for  approval  by 
NSBIT  at  a  Joint  Management/Technical  Review. 


5.7  Software  Implementation  and  Unit  Testing 

5.7.1  Software  Implementation 

The  approved  detailed  designs  will  be  implemented  in  the  ASAN  source  code.  The 
implementation  of  ASAN  Version  2.0  capabilities  will  conform  to  the  coding  standards 
previously  established  in  Version  1.0  to  ensure  consistency  of  the  code.  The  code  will 
be  implemented  under  the  SunOS  4.1.3  operating  system  and  will  then  be  ported  to 
the  Solaris  2.4  and  IRIX  5.3  operating  systems. 


5.7.2  Preparing  for  Unit  Testing 

The  preparation  of  unit  test  cases  will  be  the  responsibility  of  the  programmer  who 
implemented  an  ASAN  Version  2.0  modification.  For  each  software  unit,  test  cases 
will  be  developed  using  structural  testing  methods,  based  on  the  structure  of  the  code, 
and  functional  testing  methods,  based  on  the  functional  specifications.  The  test  cases 
will  be  recorded  and  maintained  in  the  software  development  files. 
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5.7.3  Performing  Unit  Testing 

For  each  ASAN  Version  2.0  modification,  the  affected  software  units  will  be  tested  by 
the  programmer  in  accordance  with  the  unit  test  cases. 


5.7.4  Revision  and  Retesting 

Based  on  the  results  of  unit  testing,  any  necessary  revisions  to  the  software  will  be 
performed  by  the  programmer.  The  software  imit  will  be  retested,  and  the  software 
documentation  will  be  updated  as  needed.  This  procedure  will  be  repeated  until  all 
test  cases  have  been  satisfied. 


5.7.5  Analyzing  and  Recording  Unit  Test  Results 

The  software  development  team  leader  will  evaluate  and  approve  the  results  of  unit 
testing.  The  test  results  will  be  recorded  with  the  test  cases  and  maintained  in  the 
software  development  files. 


5.8  Unit  Integration  and  Testing 


5.8.1  Preparing  for  Unit  Integration  and  Testing 

A  software  team  member  who  was  not  involved  in  the  detailed  design  and  implementa¬ 
tion  will  be  responsible  for  preparing  integration  test  cases  and  performing  integration 
testing.  For  each  build  element,  test  cases  will  be  developed  using  functional  testing 
methods.  The  test  cases  will  be  recorded  and  maintained  in  the  software  development 
files. 


5.8.2  Performing  Unit  Integration  and  Testing 

Upon  approval  by  the  team  leader  of  unit  testing  of  an  ASAN  Version  2.0  modification, 
the  affected  software  units  will  be  integrated  into  the  test  version  of  the  build  element. 
The  build  element  will  be  tested  by  the  integration  tester  in  accordance  with  the  test 


cases. 
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5.8.3  Revision  and  Retesting 

Any  problems  detected  during  integration  testing  will  be  recorded  on  a  problem/change 
report  and  submitted  to  the  team  leader.  Necessary  revisions  to  the  software  will  be 
performed  by  the  programmer.  The  software  will  be  retested  and  the  software 
documentation  will  he  updated  as  needed.  This  procedure  will  be  repeated  luitil  all 
test  cases  have  been  satisfied. 


5.8.4  Analyzing  and  Recording  Unit  Integration  and  Test  Results 

The  team  leader  will  evaluate  and  approve  the  results  of  integration  testing.  The  test 
results  will  be  recorded  with  the  test  cases  and  maintained  in  the  software  develop¬ 
ment  files. 

5.9  CSCI  Qualification  Testing 


5.9.1  Independence  in  CSCI  Qualification  Testing 

A  NSBIT  representative  will  be  responsible  for  performing  qualification  testing  of  each 
build  element. 


5.9.2  Testing  on  the  Target  Computer  System 

Each  build  element  will  be  tested  on  the  target  computer  systems,  including  the 
SunOS  4.1.3,  Solaris  2.4  and  IRIX  5.3  Unix  operating  systems.  The  software  test 
environment  will  be  further  defined  in  the  STP. 


5.9.3  Preparing  for  CSCI  Qualification  Testing 

Preparation  for  qualification  testing  of  each  build  element  will  be  performed  by  a 
member  of  the  software  team  who  was  not  involved  in  the  detailed  design  and 
implementation.  Test  cases  that  determine  whether  all  requirements  have  been  met 
will  be  developed  for  each  build  element  using  functional  testing  methods.  Necessary 
test  data  will  he  prepared.  The  test  cases  will  be  recorded  in  the  STD.  The  date  of 
qualification  testing  for  each  build  element  will  be  scheduled  with  NSBIT. 
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5.9.4  Dry  Run  of  CSCI  Qualification  Testing 

A  dry  run  of  the  test  cases  will  be  performed  before  the  qualification  test  for  a  build 
element  to  ensure  that  the  software  is  ready  for  qualification  testing. 


5.9.5  Performing  CSCI  Qualification  Testing 

For  each  build  element,  a  NSBIT  representative  will  test  the  software  in  accordance 
with  the  qualification  test  cases. 


5.9.6  Revision  and  Retesting 

Any  problems  detected  during  qualification  testing  will  be  recorded  on  a  prob¬ 
lem/change  report  and  submitted  to  the  software  development  team  leader.  Necessary 
revisions  to  the  software  will  be  performed  by  the  programmer.  The  software  will  be 
retested  by  the  development  team  and  the  software  documentation  will  be  updated  as 
needed.  Another  qualification  test  will  be  scheduled  with  NSBIT.  This  procedure  will 
be  repeated  until  all  test  cases  have  been  satisfied. 


5.9.7  Analyzing  and  Recording  CSCI  Qualification  Test  Results 

NSBIT  will  evaluate  and  approve  the  results  of  qualification  testing.  The  test  results 
will  be  recorded  with  the  test  cases  in  the  STD. 


5.10  CSCI/HWCI  INTEGRATION  AND  TESTING 

This  paragraph  has  been  tailored  out. 


5.11  System  Qualification  Testing 

This  paragraph  has  been  tailored  out. 


5.12  Preparing  FOR  Software  USE 


This  paragraph  has  been  tailored  out. 
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5. 13  Preparing  for  Software  Transition 
This  paragraph  has  been  tailored  out. 


5.14  Software  Configuration  Management 


5.14.1  Configuration  Identification 

Each  controlled  file  (program  files  and  documentation)  in  the  software  development 
Ubraries  will  be  assigned  a  unique  identifier.  The  identification  scheme  is: 

filename-(activity  #)(submission  ^). (revision  #) 

where  the  activity  number  indicates  the  software  development  activity  for  which  the 
item  is  being  submitted  for  approval,  corresponding  to  the  numbers  shown  in  Table  V. 


Table  V  Configuration  Control  Activity  Numbers 


Activity  Number 

Planning  1 

Requirements  Analysis  2 

Architectural  Design  3 

Detailed  Design,  Build  1  4 

Detailed  Design,  Build  2  5 

Detailed  Design,  Build  3  6 

Implementation,  Build  1  7 

Implementation,  Build  2  8 

Implementation,  Build  3  9 

Product  Delivery  10 


For  example,  filex-72.4  indicates  the  fourth  revision  of  the  file  named  filex  for  the 
second  submission  in  the  implementation  of  Build  1.  The  revision  numbers  will  only 
be  used  within  the  USACERL  software  development  team.  To  someone  outside 
USACERL,  the  identification  number  of  the  first  submission  of  this  SDP  is  SDP-11. 

The  identification  numbers  will  be  maintained  by  the  configuration  control  software. 
Document  identifiers  will  be  shown  on  each  page  of  the  printed  document. 
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5.14.2  Configuration  Control 

The  software  development  libraries  will  be  controlled  through  the  use  of  configuration 
control  software  that  supports  check  in  and  check  out  capabilities,  change  tracking, 
access  control,  and  archiving.  The  software  development  team  leader  will  be 
responsible  for  authorizing  and  determining  priorities  and  schedules  of  all  changes. 
Enhancements  to  be  incorporated  into  the  software  and  the  preparation  of  required 
documents  will  be  authorized  based  on  the  schedule  shown  in  Appendix  B  of  this  SDP. 
Changes  submitted  through  the  corrective  action  procedure,  described  in  Section  5.17 
of  this  SDP,  will  be  scheduled  based  on  priority  and  category. 

The  software  development  team  leader  will  assign  access  rights  to  the  files  for  each 
team  member.  All  change  activities  will  be  documented  through  the  configuration 
control  software.  Files  will  be  marked  to  identify  revisions  that  have  been  submitted 
and  accepted. 


5.14.3  Configuration  Status  Accounting 

Records  of  the  configuration  status  of  each  item  under  configuration  control  will  be 
maintained  in  the  following  reports  in  the  software  development  files: 

•  The  monthly  status  reports,  described  in  Section  5.19.2  of  this  SDP,  contain  the 
status  of  all  software  development  activities  and  the  status  of  all  prob¬ 
lem/change  reports. 

•  The  SVD,  submitted  before  each  qualification  test,  lists  all  software  and 
documentation  comprising  the  current  version. 

Additional  configuration  status  reports  are  available  when  needed  through  the 
configuration  control  software. 


5.14.4  Configuration  Audits 

Formal  audits  are  not  required  for  this  project.  The  software  development  activities 
will  be  evaluated  in  the  Joint  Management/Technical  Reviews. 
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6.14.5  Packaging,  Storage,  Handling,  and  Delivery 

All  controlled  files  are  stored  in  the  software  development  libraries.  Daily  backups 
will  be  made  to  tape.  Baselines  of  the  initial  version  and  the  latest  accepted  version 
of  each  file  will  be  archived  on  a  separate  tape.  The  software  development  team  leader 
will  authorize  copies  made  for  submission  to  NSBIT. 


5.15  Software  Product  Evaluation 
This  paragraph  has  been  tailored  out. 


5.16  Software  Quality  Assurance 


5.16.1  Software  Quality  Assurance  Evaluations 

The  status  of  all  software  development  activities  will  be  evaluated  during  the  Joint 
Management/Technical  Reviews  to  assiire  that  each  required  activity  is  being 
performed  in  accordance  with  this  SDP  and  that  each  software  product  exists  and  has 
undergone  evaluations  and  testing  as  defined  by  this  SDP. 


5.16.2  Software  Quality  Assurance  Records 


Records  of  each  software  quality  assurance  activity  will  be  maintained  in  the  software 
development  files.  These  records  will  include  status  reports,  Joint  Management/ 
Technical  Review  notes  and  summary  reports,  problem/change  reports,  test  cases  and 
results,  and  a  copy  of  all  software  documents  prepared  for  this  project. 


5.16.3  Independence  in  Software  Quality  Assurance 

NSBIT  will  conduct  software  quality  assurance  evaluations  during  each  Joint 
Management/Technical  Review.  Problems  in  software  products  or  activities  required 
by  the  SOW  or  described  in  this  SDP  will  be  handled  as  described  in  Section  5.17. 
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5.17  Corrective  Action 


5.17.1  Problem/Change  Reports 

The  problem/change  report  form  in  Appendix  A  will  be  used  to  describe  each  problem 
detected  in  the  software  and  each  problem  in  activities  described  in  this  SDP  or 
required  by  the  SOW.  These  reports  will  serve  as  input  to  the  corrective  action 
system. 


5.17.2  Corrective  Action  System 

The  corrective  action  system  will  be  initiated  when  a  problem/change  report  is 
submitted  to  the  software  development  team  leader.  Within  7  days  of  receiving  a 
problem/change  report,  the  team  leader  will  initiate  action  for  resolving  the  problem. 
Each  problem  will  be  classified  by  category  and  priority,  using  the  categories  and 
priorities  in  Appendix  C  of  MIL-STD-498.  Actions  taken  to  resolve  a  problem  will  be 
recorded  on  the  problem/change  report.  The  status  of  all  problems  will  be  described 
in  the  monthly  status  reports.  The  problem/change  reports  will  be  maintained  in  the 
software  development  files. 


5.18  Joint  Technical  AND  Management  Reviews 


5.18.1  Joint  Technical  Reviews 

Joint  Technical  Reviews  will  be  used  to  demonstrate  and  review  proposed  technical 
solutions,  surface  and  resolve  technical  issues,  and  evaluate  the  evolving  software 
products,  using  the  software  product  evaluation  criteria  in  Appendix  D  of  MIL-STD- 
498.  Each  review  will  be  attended  by  persons  with  technical  knowledge  of  the  software 
products  to  be  reviewed.  The  reviews  will  focus  on  in-process  and  final  software 
products,  rather  than  materials  generated  especially  for  the  review.  Table  VI  lists  a 
proposed  set  of  reviews,  including  the  software  products  to  be  evaluated  in  each 


review. 
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Table  VI  Proposed  Joint  Technical  Reviews _ 

Date  Product(s)  Evaluated 

28  Nov  95  SRS  and  Architectural  Design  SDD 

01  Feb  96  STP  and  Build  1  Detailed  Design  SDD 

21  Feb  96  Build  2  Detailed  Design  SDD 

16  Apr  96  Build  3  Detailed  Design  SDD  and  Build  1  Qualification  Test,  STD,  SUM,  and  SVD 

31  May  96  Build  2  Qualification  Test,  STD,  SUM  and  SVD 

08  Jul  96  Build  3  Qualification  Test,  STD,  SUM  and  SVD 


For  each  software  product  being  evaluated  for  acceptance,  NSBIT  will  decide  whether 
to  accept  the  product  without  further  modification,  reject  the  product  due  to  severe 
errors  (once  corrected,  another  review  will  be  conducted),  or  accept  the  product 
provisionally  (minor  errors  must  be  corrected).  Problem/change  reports  will  be  used 
to  record  any  problems  that  are  detected  in  the  software  products. 


5.18.2  Joint  Management  Reviews 

Joint  Management  Reviews  will  be  held  in  conjunction  with  the  Joint  Technical 
Reviews.  The  purposes  of  the  management  reviews  are  to  inform  NSBIT  of  the  overall 
status  of  the  software  development  activities  and  to  resolve  management-level  issues 
and  risks.  The  management  portion  of  each  review  will  be  attended  by  persons  with 
the  authority  to  make  cost  and  schedule  decisions.  A  status  report,  as  described  in 
Section  5.19.2  of  this  SDP,  will  be  provided  to  NSBIT  7  days  before  each  review. 


5.19  Other  Software  Development  Activities 


5.19.1  Risk  Management 

Identified  risks  will  be  included  in  the  monthly  status  reports,  described  in  Section 

5.19.2  of  this  SDP.  Mitigation  strategies  will  be  discussed  in  Joint  Management/ 
Technical  Reviews. 


5.19.2  Software  Management  Indicators 

Software  management  indicators  will  be  used  to  aid  in  managing  the  software 
development  process  and  in  communicating  its  status  to  NSBIT.  The  indicators  will 
be  recorded  in  a  status  report  that  will  be  submitted  to  NSBIT  7  days  before  each  Joint 
Management/Technical  Review.  The  indicators  to  be  used  include: 
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•  Accomplishments  in  the  current  reporting  period 

•  Schedule  status:  percent  complete  of  each  of  the  tasks  listed  in  the  schedule 
in  Appendix  B  of  this  SDP 

•  Problem/change  report  status:  total  number,  number  closed,  number  opened 
in  the  current  reporting  period,  and  priority  and  category  of  open  problems 

•  Milestone  performance:  planned  and  actual  dates  of  project  milestones 

•  Identification  of  current  and  anticipated  issues  and  risks. 


5.19.3  Security  and  Privacy 

This  paragraph  has  been  tailored  out. 


5.19.4  Subcontractor  Management 

This  paragraph  has  been  tailored  out. 

5.19.5  Interface  with  Software  Independent  Verification  and  Validation 
Agents 

This  paragraph  has  been  tailored  out. 

5.19.6  Coordination  with  Associate  Developers 

This  paragraph  has  been  tailored  out. 


5.19.7  Improvement  of  Project  Processes 

When  any  necessary  or  beneficial  improvements  to  the  software  development  processes 
are  identified,  proposed  updates  to  this  SDP  will  be  submitted  to  NSBIT  for  approval. 


5.19.8  Other  Activities  Not  Covered  Elsewhere  in  the  Plan 

The  ASAN  Version  1.0  data  will  be  updated  for  Version  2.0.  The  cartographic  data 
updates  for  ASAN  GRASS  data  involve  the  following  layers:  state  and  country 
boimdaries,  commercial  air  traffic  corridors,  MOAs,  national  parks,  wilderness  areas. 
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wildlife  refuges,  interstate  and  federal  highways,  rivers,  cities  and  towns,  civilian 
airports,  military  air  bases,  and  elevations.  Data  will  also  be  converted  and  updated 
bimonthly  for  MTRs.  The  data  development  effort  involves  the  following  tasks: 

•  Three  technical  tasks  will  be  accomplished  to  allow  the  user  to  determine  the 
geographic  region  where  ASAN  calculations  will  be  performed  without  having 
to  conform  to  a  tile  boundary.  These  tasks  are  to  determine:  (1)  a  projection, 
(2)  a  coordinate  system,  and  (3)  a  data  storage  mechanism  (tiling  scheme)  to 
be  used  for  all  data  layers.  The  projection  and  coordinate  system  will  require 
data  to  be  used  without  being  limited  to  a  specific  location;  however,  CONUS 
and  Alaska  will  be  considered  as  two  separate  areas.  This  work  will  be 
completed  before  beginning  the  software  design  so  the  results  can  be  used  in 
the  design. 

•  The  data  for  each  layer  will  be  revised  by  locating  current  sovuces  for  each  type 
of  data.  Each  layer  will  then  be  converted  to  the  proper  projection  and 
formatted  to  fit  into  the  storage  mechanism.  Each  layer  will  be  converted 
individually,  as  the  original  data  format  will  vary  with  the  source  of  the  data. 
This  work  will  be  completed  before  beginning  the  implementation  of  the  first 
build  so  that  the  data  can  be  used  for  testing. 

•  MTR  updates  will  be  produced  and  delivered  to  NSBIT  bimonthly.  As  new 
MTR  data  is  received,  the  current  data  will  be  examined  for  changes,  additions, 
and  deletions.  The  new  data  must  also  conform  to  the  projection  system  and 
tiling  scheme  being  used. 
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6  Schedules  AND  Activity  Network 


The  schedule  of  ASAN  Version  2.0  software  development  activities  is  shown  in 
Appendix  B.  The  data  development  schedule  is  in  Appendix  C. 
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7  Project  Organization  and  Resources 

7.1  Project  Organization 

NSBIT  is  the  ASAN  Version  2.0  sponsor  and  acquirer.  The  project  will  be  developed 
by  USACERL  under  MIPR  FQ76249500067.  Within  USACERL,  the  software 
development  will  be  performed  by  the  Planning  and  Management  Laboratory, 
Engineering  Processes  Division.  The  data  will  be  developed  by  the  Land  Management 
Laboratory,  Resource  Mitigation  and  Protection  Division.  Project  management  will 
be  conducted  through  the  Land  Management  Laboratory. 


7.2  Project  Resources 

All  development  activities  will  be  performed  at  USACERL  in  Champaign,  IL  using  the 
hardware  and  software  items  acquired  for  this  project  and  described  in  Section  5.2  of 
this  SDP.  The  work  will  be  accomplished  by  eight  software  professionals  as  depicted 
in  Figure  2. 


Figure  2  Project  Personnel  Structure 
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The  work  has  been  divided  into  two  efforts:  software  development  (SD)  and  data 
development  (DD).  Coordination  of  the  two  efforts  will  be  the  responsibility  of  the  SD 
team  leader  and  the  DD  team  leader.  The  teams  are  composed  of  the  personnel  shown 
in  Table  VII. 


Table  VII  Project  Personnel 


Role 

Name  %  Time 

Resnonsibilities 

SD  Team  Leader 

Kendra  Hoff 

100 

Coordinate,  direct,  and  review  the  work  of  the 
SD  team,  perform  administrative  tasks,  and 
report  the  team  status  to  the  sponsor 

Programmer  1 

David  Stigberg 

75 

Design,  implement  and  unit  test  the  software 

Programmer  2 

Chenping  Ni 

50 

Design,  implement  and  unit  test  the  software 

Programmer  3 

Tao  Ning 

50 

Design,  implement  and  unit  test  the  software 

User  Representative 

Sara  Ort 

100 

Perform  integration  testing  and  prepare  the 

ro  A  A  1  _ _ 1 

software  test  plan,  qualification  test  cases  and 
the  user  manual 


DD  Team  Leader 

Eric  Ohler 

50 

Coordinate,  direct,  and  review  the  work  of  the 
DD  team,  perform  administrative  tasks, 
report  the  team  status  to  the  sponsor,  and 
perform  data  development 

Data  Developer  1 

Marcus  Tooze 

100 

Perform  data  development 

Data  Developer  2 

Mark  Gibb 

25 

Perform  data  development 

NSBIT  has  provided  the  Version  1.0  software,  documentation,  geographic  database, 
and  the  original  MTR  release  to  USACERL.  No  additional  resources  are  required  from 
NSBIT  to  accomplish  this  work. 
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8  Notes 


Acronyms 

ASAN 

Assessment  System  for  Aircraft  Noise 

CSCI 

Computer  Software  Configuration  Item 

DID 

Data  Item  Definition 

MOA 

Military  Operations  Area 

MTR 

Military  Training  Route 

NSBIT 

Noise  and  Sonic  Boom  Impact  Technology  Advanced  Develop¬ 

ment  Program  Office 

SDD 

Software  Design  Description 

SDP 

Software  Development  Plan 

SOW 

Statement  of  Work 

SPS 

Software  Product  Specification 

SRS 

Software  Requirements  Specification 

STD 

Software  Test  Description 

STP 

Software  Test  Plan 

SUM 

Software  User  Manual 

SVD 

Software  Version  Description 

USACERL 

U.S.  Army  Construction  Engineering  Research  Laboratories 
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Appendix  A:  Problem/Change  Report  Form 


Versiwa  2.0 

:Bf(^leiQ/€luaige:iBepoi^ 


|^o1»l«nN«(ns: 

Onfi^teR  Orig^natifinDate: 

Strffcwmre  Baein)ait<s>  Affected:  Kle  Map  Seenaao  Opraations  RacaiveFS 

Pradwcts  CitaSws  Otater 

Flatffai»;  SunOS  4.1.3  S<daii8  2.4  IRIX  5.3 

BuMKtanlber: 

ttoeumant(s)  Affected:  SBP  STP  SRS  SDD  SfD  SPS  SVD  SOM 

Doeujaettt  ID 

Descri^aen! 


FroWmNtm*^::  Categaiy: 

Actions  fakm: 

Date  Actl<^ 


Summaiy  of  SMuiiou: 
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Appendix  B:  Software  Development  Schedule 


ASAN  ?  0  Sohwaro  Oovelopruuiil 
IU/^2/95 
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AS  AN  2  0  Sotiwaro  Dovolophtoiii 
10/12/95 


5/30/96 


ASAN  2  0  Soliwaro  Dovelopinunl 
10/12/95 
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Appendix  C:  Data  Development  Schedule 
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